FIG. 1 shows a configuration example of a conventional web-based network system used on the Internet. In FIG. 1, Pull-style communication is established in which a request is placed from a web browser group (client group) 3 to a business application group (application server group) 2 which uses a database (database server) 1, and a response is sent to the web browser group 3 in return. Note that in this web-based network system, a request from the web browser group 3 is a communication trigger, and hence Push-style communication initiated by the business application group 2 on the server side toward the web browser group 3 is not available.
To deal with demands of the server for the Push-style communication, a bus system, for example, is used.
The ESB is one example of a publicly known bus concept, and various studies have been conducted thereon (see, for example: www.atmarkit.co.jp/aig/04biz/esb.html). The ESB refers to an architecture configuration which integrates applications based on the SOA (Service Oriented Architecture) having a “bus” concept, or refers to a software product which serves as the base for providing such an architecture configuration. The ESB concept is a software design notion of building an SOA system, which makes accesses to services (applications and components) and enables coordination and cooperation of multiple services, on the basis of a logical software bus. Accordingly, although its specific functions and implementation are different among individual products and systems, the ESB generally refers to EAI (Enterprise Application Integration) products having a standard SOA interface; sophisticated message buses supporting multi-protocols; or integrated middleware technologies and middleware products having such a message bus. That is, the ESB functions as an integration intermediary enabling mutual cooperation of services developed compatible with open standard specifications, such as web services and JCA (J2EE Connector Architecture). A core message bus supports standard protocols, such as HTTP (Hyper Text Transfer Protocol), SOAP (Simple Object Access Protocol), and JMS (Java (registered trademark) Message Service), provides functions including “publish and subscribe”, “store-forward message” and “routing”, and incorporates services in/out of synchronization. In a complete SOA environment, the ESB can employ a distributed processing architecture; however, many actual ESB products also have legacy connection and data conversion features, and thus can be used as EAI in a broad sense. Furthermore, some ESB products provide functions of security, load distribution, process modeling and the like.
FIG. 2 shows a configuration example of a conventional bus system. A bus system BS is interposed among applications AP1-AP6 . . . to mediate all communication between the applications, whereby both Pull-style communication and Push-style communication can be freely performed. Note that communication between the bus system BS and each application AP1-AP6 . . . is made possible in various ways, such as by HTTP, SOAP, JMS and the like.
Such a conventional network bus system processes server applications and user applications connected to the bus system by communicating with them one at a time. Therefore, with an increase in the number of server applications and user applications connected to the bus system, the bus system needs to accommodate and be able to process the increased workloads.
One example of implementing load distribution is building a bus system with multiple processes and enabling interprocess communication, thereby distributing workloads. Specific examples of such load distribution are “ESB Mule model”, “endpoint ESB”, “Artix” and “Celtix”. The “ESB Mule model” is a lightweight messaging framework having a distributed object intermediary for managing communication between applications (www.mulesource.org/display/JPNDOC/Architecture+Overview). The “endpoint ESB” is based on the concept of aggregating everything at endpoints, and forms an ESB by combining the endpoints (www.mulesource.org/display/JPNDOC/Mule+Endpoints; and www.blogs.iona.com/essence/2006/11/esb—1.html). One implementation example of the endpoint ESB is “Artix”, which is an ESB following the CORBA (Common Object Request Broker Architecture) standard. “Celtix” is an open source ESB (www.celtix.objectweb.org/).
FIG. 3 shows a configuration example of a conventional bus system in which load distribution is achieved using multiple processes. In FIG. 3, the bus system BS accessed by the applications AP1-AP5 includes processes P1-P5. Communication is controlled using interprocess communication between respective processes P1-P5, whereby load distribution is achieved. Herewith, even if the number of applications increases, scale-out of the bus system (i.e. improving the performance of the entire bus system BS by increasing the number of processes) can be achieved.
Patent Document 1: Japanese Laid-open Patent Application Publication No. H09-307583
Infrastructure for developing and implementing new communications services by combining existing phone services and data-based services, such as e-mail services, has been studied in recent years. The new infrastructure is expected not only to provide existing line switching services in a SIP-based (Session Initiation Protocol based) packet network, but also to enable the addition of novel functions. One example of such infrastructure is the SDP (Service Delivery Platform) implemented in the NGN (Next Generation Network).
In an NGN environment, a great number of users are likely to access server applications via a bus system. In particular, if a certain service becomes popular, it is often the case that a large number of users make accesses to the service at one time. In such a situation, there are limitations to scale-out with the use of the above-mentioned existing bus-system technologies or the implementation of such a bus system. That is, if the number of users drastically increases and accesses are concentrated on a certain application, such scale-out capabilities are not sufficient to deal with the situation.
FIG. 4 shows load concentration on certain server applications and processes. In FIG. 4, the bus system BS includes multiple processes P1-P5, on the upper side of which a server application group (server applications A1, A2, B1, C1 . . . ) is depicted, and on the lower side of which a user application group (user applications U1-U4 . . . ) is depicted. Each application is connected to one of the processes P1-P5 forming the bus system BS. Interprocess routing is provided among the processes P1-P5, thereby achieving load distribution. Note that the server applications A1 and A2 provide the same service (application A).
Assume here that the application A gains popularity. Accesses from the user application group (the user applications U1-U4 . . . ) concentrate on the popular application A (server applications A1 and A2) at once, and the communications traffic becomes high. In addition, the number of user applications in the user application group grows with a rumor or trend that the application A has a high popularity. The number of user applications could reach hundreds of thousands to several millions. Such numerous user applications U1-U4 . . . all together initiate accesses to the server applications A1 and A2.
The communications traffic is processed by the multiple processes P1-P5; however, workload imbalance is generated among the processes P1-P5. The workload is particularly concentrated on the terminal process P1 which performs direct communication with the server applications A1 and A2. The bus system BS cannot prevent the load concentration, and as a result, the scale-out of the bus system BS becomes difficult.
Thus, the conventional bus system has limitations in its scale-out capabilities when workload concentration occurs, and accordingly, the scale-out of the bus system cannot be achieved.
Patent Document 1 discloses a super agent for transmitting and receiving data between common memories of individual servers each having databases. However, in this technology also, the workload is concentrated on the inter-router communication and the super agent itself, and the scale-out is therefore difficult to achieve.
In addition to the above-described load concentration, there is another problem that each application cannot perform communication unless an application to be a communication target is determined. For example, what users usually want is services provided by server applications, and it is not always the case that they can identify server applications which offer the users' desired services. In particular, in the case where server applications offering similar services (e.g. search services) are newly created and gone very often, it is unreasonable to expect that users are able to identify their target server applications.